This PR kicks off the repeat_row productionization work stream. Resolves SQL-160. Resolves SQL-161.

I suggest reviewing commit by commit:

1. just some renamings to match up internal names to the SQL name
2. Add repeat_row_non_negative as a new SQL function, which errors out on a negative input (instead of producing a negative number of rows). It's less powerful than repeat_row, but its advantage is that it doesn't have the restrictions and dangers that repeat_row has. The immediate motivation for this was to be able to keep using this in tests of WITH ORDINALITY when repeat_row is disallowed, but it might also be useful for users for other purposes, so users could be allowed to freely use it. (For now, it's guarded by a feature flag which defaults to off, and I haven't documented it yet, but if we think this would be indeed a useful function for users, then I can add docs and turn it on in a follow-up PR.)
3. The main point of the PR: disallows repeat_row in WITH ORDINALITY and in some other constructs that are implemented using WITH ORDINALITY. We need to make this change for productionizing repeat_row, because WITH ORDINALITY is not well-defined for negative diffs, and the implementation panics on a negative diff. (Note that this is not violating backwards compatibility requirements, because repeat_row was not officially supported so far, and has not been turned on for most users.)

Note: An alternative to disallowing repeat_row with WITH ORDINALITY would be to make WithOrdinality::eval not panic on negative diffs. However, this seems to be not easily possible without a performance hit or complicating the code: We'd need to either

• eval the table function twice, only checking the diffs at the first evaluation, costing CPU;
• save the eval result in a Vec, costing memory;
• make the flat_map closure somehow fallible, for which I don't see an easy way. (E.g., we could make the iterator's item type Result, but then would need to touch every caller of TableFunc::eval and every arm of the big match in TableFunc::eval, and might slow things down a bit. Or we could report the error in an Rc<Cell<...>>, which also feels convoluted, and potentially costing CPU.)

We could reconsider making it possible generally to return errors in the middle of table function iterators, if we ever find a need for this in some other table function. But repeat_row together with WITH ORDINALITY feels so rare, that it seems ok to just disallow this combination for now. Edit: https://github.com/MaterializeInc/database-issues/issues/11324 would be one more reason to implement error returns inside this iterator, but that issue seems also quite low priority.